Currently, a user may use their mobile device, such as smartphone or tablet, as a user interface (UI) for another piece of hardware. The conventional way to provide the user interface to a user of a mobile device is to download an application (App) from Google Play, the Apple App Store, or other vendor onto the phone or tablet. The App is made specifically for the given mobile device (i.e. Android or Apple) and for the given piece of hardware. That App then interfaces with the piece of hardware wirelessly.
The downloaded application is pre-configured for a specific type of hardware, and is generally registered or linked before use to a single target hardware such as a heart rate monitor, thermostat, keyless entry to your home or a painting in an art gallery that delivers the information to the mobile device to present the information on the user interface in a predefined format.
Currently, the user needs a separate App for the specific mobile device and for each of the pieces of hardware types that are communicating with the mobile device. The user may therefore need to use thousands of applications. The conventional system requires a user to identify the hardware to a mobile device, know the name of the App that is needed for the communication, go to the App Store, log-in, download the app, install the App, configure the app, learn how to use the App, then associate the App with the hardware to which you want to interface. Also there had to be some sign at the hardware location leading you to the name of the App you need to download to even get that far. That is all for just one single device, the user would need to repeat this for every device.
A web-server using a WiFi device may also be used to present a user interface to a user from a separate hardware device. This means a WiFi host device is mounted at the hardware or other location where data is to be communicated. Then, when the mobile device (such as the smartphone) is near the hardware device, the user must navigate the WiFi settings on the mobile device, search for a network, connect to the network, exchange security credentials, establish a connection, then launch a browser (hope the browser will be compatible with the HTML and controls used by the target hardware), then download HTML and render the UI for the user on the mobile device. That is for one location and one hardware. Once you move to the next hardware device, the user will need to repeat this process again, to get the next hardware association. Once the user makes one association, the mobile device will drop the prior one, as the device can only connect with one WiFi target (or in this case host) at a time. Aside from the web server needing a large memory footprint to run, WiFi consumes a lot of power and is not suited for battery powered applications which is needed for practical applications.
Accordingly, the available approaches for rendering a user interface on a mobile device of unconnected hardware need a lot of user knowledge and manual intervention. Accordingly, present options are not very practical for the major stakeholders.
Device manufacturers have to employ multiple software development teams for each product (embedded, Android, iOS, Windows), and the applications that are usually given away, end up costing the company a lot of money for development, and add risk to the overall product life cycle. Additionally, the end customers have to manage the complexity of knowing which application to download, or know how to connect to a temporary WiFi network.
Handling hardware based applications is also very costly to the distributor of applications, such as the app stores for Google, Apple, and Microsoft. Currently, the developer of an application based on hardware needs to ship their hardware along with their software app to the app store for review and approval. This process is conventionally required as it is the only effective way to confirm the app functions properly with the associated hardware. This process is expensive for the administrators of these app stores, as it is labor intensive to receive, catalog, test, and verify the applications before posting. Moreover, hardware based applications are typically provided for free as they come to the customer with the cost of the hardware. Therefore, the app store does not typically generate revenue on these applications, but expends substantial cost. Apple, Google, Microsoft and other administrators of app stores benefit from the present invention by reducing or eliminating these overhead costs for non-revenue generating applications.